POV-Ray : Newsgroups : povray.binaries.scene-files : Quantum Waves in Media : Re: Quantum Waves in Media - 3 attachment Server Time
19 May 2024 04:01:51 EDT (-0400)
  Re: Quantum Waves in Media - 3 attachment  
From: Jaap Frank
Date: 26 Jan 2003 16:49:33
Message: <3e3457ed@news.povray.org>
> > I hope that you post the radius formula when
> > you find it Jaap.
>
> I think that the old fashioned formula for the Bohr
> Radius might be a good choice to start with.
> I have to test it jet.
[..]
> If I have tested these things, I will let you know what
> the solution for this will be (if I can find it).
>

It took me a while to find a formula for the container radius, but I've found
something useful.
The following you can find in the attached file too.
(As you suggested I've changed the variables to upper case.)

/*  Container formula:
  The Bohr radii are proportional with N*N.
  For N=1 the quantum maximum equals the Bohr radius when R = 1,
  but for N=2 it's around 5*R instead of the expected 4*R.

  For the quantum functions I've found some interesting correction factors when
L = 0:
  - With N > 2 else it's nonsense.
  - The main maxima are around:    N*N * (N-1)/(N/2)
  - The fall off towards nearly zero: N*N * (N-1)/(N/2) * (N-1)/(N-2)
  - Expansion for very low values:  N*N * (N-1)/(N/2) * (N-1)/(N-2) * (1 +
0.4/N)
  It doesn't give the exact maxima, but it's amazingly close. The limit (N >>>)
is 2*N*N.

  L > 0:
  The deviation between the quantum maxima and the Bohr radii becomes smaller
for
  larger values of L.
  The maximum of the 2p is nearly 4*R, of the 3d it's nearly 9*R and of the 4f
nearly
  16*R.  The maxima of the 4p and 4d are between the 4s and the 4f.
*/

As you can see there is a regularity in the maxima. I was led by the fact that
these kind of factors are used in the wave function too, but it was trial and
error at first. The last factor contains 0.4 and is only a choice to keep the low
density part visible.
It can become smaller with increasing N, because the whole density is lower
then (total volume is 1 because of the normalization factor).

Further there are some small optimisations with pow() when the power is zero
or one. The speed increase was noticeable but not great. Well, all small steps
help.

I removed a bug from the macro CreateAxis() and made it ready for high
values of N.

Curiosity made me try some very high values of N, up to 100. With N=100
there's nothing to see. I went down and with N=77 it appears suddenly again,
although with very bad quality.
First I was puzzled about this, but 77 was somehow a familiar number. Then I
remembered that that is the maximum number for facultity in a normal calculator.
There are lots of facultities in the formula, so this must be the cause of this.

This brings me to another subject.
About a year ago I was trying to understand the working of  poly.cpp of the
source code of POV-Ray (3.1g). What I was (and still am) is figuring out
how a polynomial of high degree is solved for its roots.
I cannot code in C, but I've coded in Pascal (TurboPascal), so I can follow
(with some difficulty) what is done there.
In PolySolve the binomial(int n, int r) is heavily used, so I tried to figure
out
how that was done. In the loop there is a 'Goto' to get out of the loop when
something is found and done. That was the point where I couldn't follow it
anymore. To my opinion this was not done correctly, so a bug.
To proof myself, I coded this function in SDL and compared the results
with the strait forward method that I use in the wave functions too.
(Attachment Test_PolyC). It proofs that I was right about it. It's a bug.
Years ago I had poly.cpp printed from POV version 2_?  for another
reason and to my surprise the bug was already there. I think it may exist
from the beginning of POV-Ray!
In that time I hadn't internet (I was very late with that) and got POV_Ray
from a friend, so I couldn't report it. Because for the first 15 powers
there is a look up table it is possible that this bug doesn't show up, for
MaxPower = 15. Further I thought that this must be known and nobody
bothered about it.
To my surprise the bug still exists in version 3.5. It's possible that this
part is still unused, but maybe with the new possibilities with the functions
there is need for solving higher powers and then there is a problem with this
function.
I think it's no use that I report this, for I once found a strange behaviour
with brackets during the beta testing period, but got no reaction about this
after I had reported that.
Maybe they listen to you.

What do you think about this?

Regards,

Jaap Frank

PS Is your email tor### [at] hotmailcom still active?
      Bonus: A nice wave :).


Post a reply to this message


Attachments:
Download 'H_Wave_Functions v4_TOR_4.pov.txt' (29 KB) Download 'Test_PolyC.pov.txt' (14 KB) Download 'H_PROB_7H-3_MED_TOR_4.png' (363 KB)

Preview of image 'H_PROB_7H-3_MED_TOR_4.png'
H_PROB_7H-3_MED_TOR_4.png


 

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.